-
Notifications
You must be signed in to change notification settings - Fork 896
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exception reporting specification #697
Exception reporting specification #697
Conversation
Co-Authored-By: Armin Ruech <armin.ruech@gmail.com>
268225d
to
4a1fbe8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This aligns very well with what the Go SDK has implemented, though we have RecordError()
rather than RecordException()
. That's a pretty easy change for us to make at this point. I like it.
This looks like just what we need for the 1.0 GA release. It is very important to get this merged so work needed for the SDK GA releases can proceed. |
LGTM but I strongly recommend to decide on open-telemetry/oteps#123 before merging this (even if the decision is just "we will use #697 for GA and consider open-telemetry/oteps#123 later). |
|
||
## API | ||
|
||
To facilitate recording an exception languages SHOULD provide a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For an alternative idea see open-telemetry/oteps#123 (comment) and following comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just catching up on this working group now -- great work everyone!
General comment: this is very exception focused, but an exception is just a type of error. OpenTracing semantic conventions based everything on errors (https://opentracing.io/specification/conventions/) so you could have an error.kind
of exception
and then all key names would be based on error (e.g. error.type
instead of exception.type
). Was this approach considered?
@flands The general sentiment was exactly the opposite: we record an exception, which may or may not be an error. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 👍
EDIT: I think it is completely fine to move the discussion in #697 (comment) to a follow up.
The bikeshedding in #697 (comment) about exception.stacktrace
vs something that does not make one believe it is OK to only put the stacktrace without exception message there would be nice to also resolve before merging because it is a breaking change, but I can create a follow-up PR for this too.
I stay on my opinion that this should be left to language SIG. To specify a recommended format of that field content. |
@open-telemetry/specs-approvers @open-telemetry/specs-trace-approvers can somebody merge this, please? |
* Add semantic conventions for errors * Update error.type description Co-Authored-By: Armin Ruech <armin.ruech@gmail.com> * update semantic conventions for exceptions * add details for attributes; remove log.severity; add API details * rename exceptions.md -> exception-reporting.md * more accurately describe format for java * alphabetize languages in stacktrace representation table * prefer dynamic type over static type * add log.severity convention * Revert "add log.severity convention" This reverts commit 137556e. * rename stacktrace -> exception.stacktrace * move file to semantic conventions directory * move RecordException to API * fix formatting Co-authored-by: Armin Ruech <armin.ruech@gmail.com>
* Add semantic conventions for errors * Update error.type description Co-Authored-By: Armin Ruech <armin.ruech@gmail.com> * update semantic conventions for exceptions * add details for attributes; remove log.severity; add API details * rename exceptions.md -> exception-reporting.md * more accurately describe format for java * alphabetize languages in stacktrace representation table * prefer dynamic type over static type * add log.severity convention * Revert "add log.severity convention" This reverts commit 137556e. * rename stacktrace -> exception.stacktrace * move file to semantic conventions directory * move RecordException to API * fix formatting Co-authored-by: Armin Ruech <armin.ruech@gmail.com>
This PR is another take on exception / error reporting. It's based on #427 and conversations from the errors working group. Below is a summary of differences between this proposal and #427:
Span.RecordException
API methodThe goal of this PR is to solve the 90% use case, without painting ourselves into a corner for future improvements.